Codecov Report

✅ All modified and coverable lines are covered by tests.

@@              Coverage Diff              @@
##             develop    #3509      +/-   ##
=============================================
+ Coverage      59.57%   59.63%   +0.06%     
  Complexity       105      105              
=============================================
  Files           3006     3006              
  Lines         130472   130474       +2     
  Branches        9639     9640       +1     
=============================================
+ Hits           77720    77789      +69     
+ Misses         49848    49770      -78     
- Partials        2904     2915      +11     

@sfeilmeier, I would appreciate if you could review this. I've analyzed the issues related to evcc usage, referencing both the KACO implementation (https://community.openems.io/t/setactivepowerlessorequals-verhalten/10697/7) and the GoodWe (FENECON) implementation (already referenced). Sadly I've not found a solution for the KACO device as it looks like it's not about the implementation by OpenEMS (probably related to firmware/external library?). I cannot fiddle out the reason for PV routing for those.

It's related to the prevent discharge function implemented by the opemens template in evcc.

Because I have no hardware to test, you need to take it as theoretical work and someone else needs to the testing. It's additional unit tests are based on real-world scenarios and proove to solve the issue. Users having issues are FEMS users and because of this a test is not possible easily.

@sfeilmeier friendly reminder to discuss?

Thanks for the analysis, but I believe the current behavior is actually correct.

activePowerSetPoint represents the desired AC output power of the ESS - it does not mean "battery power". When activePowerSetPoint == 0, it means: "The ESS should produce 0W on the AC side." If PV is producing 300W and 0W should go to AC, then charging the battery with the surplus 300W is the correct behavior. The PV energy has to go somewhere.

The existing logic in handleRemoteMode is consistent:

pvProduction (300) >= activePowerSetPoint (0) → CHARGE_BAT, pvProduction - activePowerSetPoint = 300

This means: "Feed activePowerSetPoint to AC, charge the battery with the rest of PV." That's exactly what should happen.

Your proposed fix (DISCHARGE_BAT, 0) would leave the 300W PV production unaccounted for - the behavior then depends entirely on how the GoodWe inverter internally handles that case, which is undefined.

If evcc wants to keep the battery neutral while still using PV for household consumption, the constraint needs to be expressed differently - this is not a bug in handleRemoteMode, but a semantic mismatch in how the constraint is set by the external controller.

Thanks for your feedback. Yes, I realized from the discussion which started afterwards.

Let's not think about evcc here too much. Of course I'd appreciate a solution to successfully avoid discharging the battery on those external loads. It is clear to me that the use case needs to be resolved. That's another discussion ;-)

I would appreciate if somebody, best those who wrote the case, could clarify the reason for and take the proposal into account. I also see a dependency how the device is handling energy of course. Without a hardware and clear understanding about how it is supposed to get controlled this cannot be decided.